Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-cameron-cmp-00.txt < prev next >

Wrap

Text File | 1993-04-21 | 25.3 KB | 724 lines

Internet Draft P. Cameron J. Bates Xylogics, International Ltd. April 1993 Connection Multiplexing Protocol (CMP) Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. It is intended that this document will be submitted to the IESG for consideration as a standards document. Distribution of this document is unlimited. Abstract One of the problems with terminal servers attached to a LAN is the large number of small packets they can generate. Frequently, most of these packets are destined for only one or two hosts. CMP is a protocol which allows multiple Telnet and Rlogin connections, between a server and a host, to share a single TCP connection. With simple extensions this can be expanded to include other TCP protocols. Acknowledgments This document is the work of many more contributors than just the listed authors both here at Xylogics International and at Xylogics Inc. Specifically Jim Barnes, Gary Malkin, James Carlson, Dave Hirst and Miguel Sasson. In addition, we would like to thank ICL Plc. in the U.K. and Sweden for reviewing early versions of this proposal, and for their assistance on early prototypes. Cameron, Bates Expires: 20 Oct 93 [Page 1] Internet Draft CMP April 1993 Table of Contents 1. Justification . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Header Format . . . . . . . . . . . . . . . . . . . . . . . 3 3.2 Opening a Multiplexed Connection . . . . . . . . . . . . . . 4 3.3 Opening a New Subconnection . . . . . . . . . . . . . . . . 6 3.4 Sending Data . . . . . . . . . . . . . . . . . . . . . . . . 6 3.5 Urgent Data . . . . . . . . . . . . . . . . . . . . . . . . 6 3.6 Subconnection flow control . . . . . . . . . . . . . . . . . 7 3.7 Closing a Subconnection . . . . . . . . . . . . . . . . . . 8 3.8 Closing a Multiplexed Connection . . . . . . . . . . . . . . 9 3.9 Standard Error Codes . . . . . . . . . . . . . . . . . . . . 9 4. Multiplexed Messages . . . . . . . . . . . . . . . . . . . . . 10 4.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2 Disassembly . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 1. Justification When network designers consider which protocols generate the most load, they naturally tend to consider protocols which transfer large blocks of data (e.g. FTP, NFS). What is often not considered is the load generated by Telnet and Rlogin because of the assumption that users type slowly and the packets are very small. This is a grave underestimation on networks which have many Telnet and Rlogin ports on multiple terminal servers. The problem stems from the fact that the work a host must do to process a 1-byte packet is very nearly as much as the work it must do to process a 1500-byte packet. That is, it is the overhead of processing a packet which consumes a host's resources, not the processing of the data. If one assumes that most users connected to a terminal server will be connecting to only a few hosts, then it should be obvious that the network and host load could be greatly reduced if traffic from multiple users, destined for the same host, could be sent in the same packet. 2. Overview CMP is designed to improve network utilization and reduce the load on the hosts by multiplexing TCP connections, which would otherwise generate many small packets, onto a single TCP connection which generates fewer, larger packets. Cameron, Bates Expires: 20 Oct 93 [Page 2] Internet Draft CMP April 1993 The following terminology is used throughout this document. Multiplexed Connection - The actual TCP connection which exists between the server and the host over which the subconnections exist. Subconnection - The "virtual TCP" connection between processes on the server and host which exists over the Multiplexed Connection. Message - A single packet of data for a single subconnection plus its header which is passed over the Multiplexed Connection. Endpoint - One of the two ends of a subconnection. 3. Protocol Design CMP operates by prepending a 4 octet header onto each subconnection's data, then appending that onto the end of the packet which will be sent over the multiplexed connection. Upon receiving a message, the individual subconnection datastreams are demultiplexed and the information is handed up to the application. 3.1 Header Format The 4 octet header has the following general format: | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-----------+-------------------+ | TYPE | SIZE high | +-----------+-------------------+ | SIZE low | +-------------------------------+ | Dest ID (DID) high | +-------------------------------+ | Dest ID (DID) low | +-------------------------------+ The TYPE field has the following values: 0 - data (DATA) 1 - urgent data (URG_DATA) 2 - open subconnection (OPEN) 3 - reply to OPEN message (OPEN_RPLY) 4 - close subconnection (CLOSE) 5 - reply to CLOSE message (CLOSE_RPLY) 6 - credit update (CREDIT) Value 7 is reserved for future use. For most commands, the SIZE field contains the number of octets of 'data' following the header. For messages of type DATA and URG_DATA this will be the number of data octets, for other messages, this will Cameron, Bates Expires: 20 Oct 93 [Page 3] Internet Draft CMP April 1993 be the number of octets contained in subsidiary header fields. For the CREDIT message, this field contains the number of bytes of new credit available for the receiving end to use. The DID is an arbitrary 16-bit number assigned by the receiving end of a subconnection to identify the subconnection. The receiver of a message uses the DID to uniquely identify a subconnection. Note, this field is not used by the OPEN message as no destination has been allocated. 3.2 Opening a Multiplexed Connection The first time an endpoint tries to open a TCP connection to a host, it first attempts to create a Multiplexed Connection by opening to the CMP port, TBA. If that attempt succeeds (i.e. a TCP connection is established), the server sends an OPEN message. If the Multiplexed Connection cannot be established, the server should open a standard TCP connection directly to the specified remote port. The format of an OPEN message is: | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-----------+-------------------+ | 2 | 0 | +-----------+-------------------+ | 6 | +-------------------------------+ | 0 | +-------------------------------+ | 0 | +-------------------------------+ | Source ID (SID) high | +-------------------------------+ | Source ID (SID) low | +-------------------------------+ | Dest port high | +-------------------------------+ | Dest port low | +-------------------------------+ | Initial Credit high | +-------------------------------+ | Initial Credit low | +-------------------------------+ The SID is an arbitrary number, for example, it could be the index into an internal table of connections. See discussion below on the use of this field. The TYPE is 2, indicating the opening of a new, in this case first, subconnection. The DID field is not used as no destination has yet been allocated. The Dest Port is the well known TCP port number for the application (e.g. 23 for Telnet). The initial credit is the number of octets of data that the endpoint opening the connection can initially receive from the other endpoint. The receiver of the open message will respond with an OPEN_RPLY Cameron, Bates Expires: 20 Oct 93 [Page 4] Internet Draft CMP April 1993 message. The format of an OPEN_RPLY message is: | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-----------+-------------------+ | 3 | 0 | +-----------+-------------------+ | 6 | +-------------------------------+ | Dest ID (DID) high | +-------------------------------+ | Dest ID (DID) low | +-------------------------------+ | Source ID (SID) high | +-------------------------------+ | Source ID (SID) low | +-------------------------------+ | Initial Credit high | +-------------------------------+ | Initial Credit low | +-------------------------------+ | Error code (ERR) high | +-------------------------------+ | Error code (ERR) low | +-------------------------------+ If the receiver cannot open the subconnection for any reason, it will respond with an OPEN_RPLY message with a non-zero ERR field (and a SID field of 0). If the receiver succeeds in opening the subconnection, the ERR field of the OPEN_RPLY will contain zero. See section 3.9 for a list of standard error codes. The initial credit is the number of octets of data that the endpoint can initially receive from the other endpoint. It is important to note the use of the SID fields in both the OPEN and OPEN_RPLY messages. This field is used to pass to the other endpoint the value to be used in the DID field of all subsequent messages sent back on this Subchannel. In particular, the DID field of the OPEN_RPLY message should be set from the SID field of the OPEN message. Optionally having different DID fields in the two directions allows the implementor of each end much greater freedom in the use of the DID field, hence the opportunity to make the implementation more efficient. For example, if the endpoint has a table of information about each open subconnection, then the DID can be the index into this table. This is a much more efficient implementation that scanning the table and much easier to implement than a hash table lookup. Cameron, Bates Expires: 20 Oct 93 [Page 5] Internet Draft CMP April 1993 Thus, the sequence of messages and their SIDs and DIDs could be: Endpoint 1 Endpoint 2 ---------- ---------- TYPE=OPEN ---------------> DID=0 SID=D1 TYPE=OPEN_RPLY <---------------- DID=D1 SID=D2 TYPE=DATA ---------------> DID=D2 TYPE=DATA <---------------- DID=D1 3.3 Opening a New Subconnection When a user on a server attempts to open a TCP connection to a host for which a Multiplexed Connection exists, the server simply adds that TCP connection as a new subconnection by sending an OPEN message and receiving back an OPEN_RPLY message (see section 3.2). Once a Multiplexed Connection has been established, either side may initiate an OPEN request. 3.4 Sending Data Subconnection data is preceded by the following header: | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-----------+-------------------+ | 0 | Length high | +-----------+-------------------+ | Length low | +-------------------------------+ | Dest ID (DID) high | +-------------------------------+ | Dest ID (DID) low | +-------------------------------+ The DID is the identification for the subconnection. The TYPE is 0. The Data SIZE field specifies the length of the data immediately following the header; it does not include the length of the header. Cameron, Bates Expires: 20 Oct 93 [Page 6] Internet Draft CMP April 1993 3.5 Urgent Data TCP requires the ability to send individual octets marked as "urgent" data. When an application requests this, it expects that the remote end of the communications stream is notified as soon as possible that urgent data are pending, and it expects that the remote end will be able to mark this octet and deliver it either in-line or as out-of- band data. This feature is implemented over a Multiplexed Connection using an URG_DATA message. The format of the urgent data message is: | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-----------+-------------------+ | 1 | Length high | +-----------+-------------------+ | Length low | +-------------------------------+ | Dest ID (DID) high | +-------------------------------+ | Dest ID (DID) low | +-------------------------------+ The DID is the identification for the subconnection. The TYPE is 1. The SIZE field indicates the number of bytes of urgent data being sent. Some implementations may choose to expedite the transmission of data preceding and including the urgent data message. 3.6 Subconnection Flow Control CMP supports flow control on a subconnection basis to ensure that a single subconnection can not tie up vast amounts of resources to the detriment of the other subconnections. Flow control in CMP is accomplished by use of a credit/debit system. Each endpoint knows the maximum number of octets of data (contained in messages of type DATA) that the other endpoint is able to receive, and may not send more than this number, it can of course send less. After sending a DATA message, the endpoint should decrease its outstanding credit by the number of octets just sent. Once the other endpoint has processed the data, it will send back CREDIT messages to tell the sending endpoint how many more octets of data it can now receive. Note, an endpoint can send CREDIT messages when it wishes to, there are no constraints on the timing, and it may not grant back to the other endpoint all the credit it initially had (or it may grant more). The format of the CREDIT message is: Cameron, Bates Expires: 20 Oct 93 [Page 7] Internet Draft CMP April 1993 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-----------+-------------------+ | 6 | Extra credit high | +-----------+-------------------+ | Extra credit low | +-------------------------------+ | Dest ID (DID) high | +-------------------------------+ | Dest ID (DID) low | +-------------------------------+ The DID is the identification for the subconnection. The TYPE is 6. The extra credit field is the number of octets of data space that have become available at the endpoint sending the message. This value should be added to the credit value currently held. After an OPEN message, the credit available is given in the initial credit field of the OPEN or OPEN_RPLY message. Only messages of type DATA are controlled by the credit/debit system, all other messages (including URG_DATA) can be sent at any time. 3.7 Closing a Subconnection When one side of the subconnection wishes to close, it sends a CLOSE message. This indicates that there is no more data to be sent. After sending this message an endpoint MUST NOT send any more data. The side which receives the Close Request continues to send data until there is no more data to be sent, at which time it sends a CLOSE_RPLY message. A CLOSE message has the following format: | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-----------+-------------------+ | 5 | 0 | +-----------+-------------------+ | 1 | +-------------------------------+ | Dest ID (DID) high | +-------------------------------+ | Dest ID (DID) low | +-------------------------------+ | Close type | +-------------------------------+ The DID is the identification for the subconnection. The TYPE is 5. The close type field contains the type of close to be done: 0x00 Standard close 0x01 Reset. A standard CLOSE will allow all data currently in transit to be sent, Cameron, Bates Expires: 20 Oct 93 [Page 8] Internet Draft CMP April 1993 but a reset CLOSE will cause this data to be flushed. The CLOSE_RPLY message has the following format: | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-----------+-------------------+ | 6 | 0 | +-----------+-------------------+ | 2 | +-------------------------------+ | Dest ID (DID) high | +-------------------------------+ | Dest ID (DID) low | +-------------------------------+ | Error code (ERR) high | +-------------------------------+ | Error code (ERR) low | +-------------------------------+ The DID is the identification for the subconnection. The TYPE is 6. The ERR field is used to return an error code. A value of 0 is used where the Close was successful, a non-zero value indicates an error. See section 3.9 for a list of error codes. A subconnection is not closed until one endpoint issues a CLOSE Request, and the other endpoint responds with a CLOSE_RPLY message. Note, the subconnection is closed on receipt of the CLOSE_RPLY message, regardless of the value of the ERR field. Where the close type is 'reset' the receiver should send the CLOSE_RPLY message immediately, it should not wait for data to flush. If an endpoint sends a normal CLOSE message, and does not receive a CLOSE_RPLY message it is permissible to send a second CLOSE message with a 'close type' of 'reset'. In this situation it must be possible to cope with receiving either 1 or 2 CLOSE_RPLY messages. 3.8 Closing a Multiplexed Connection When the last subconnection on a Multiplexed Connection has closed, the Multiplexed Connection should also be closed, as any TCP connection would be. 3.9 Standard Error Codes The standard error codes to be used in the ERR field of the OPEN_RPLY and CLOSE_RPLY messages are: ESUCCESS 0 Command completed successfully ENXIO 5 No such device or address ENOMEM 8 Not enough core EACCES 9 Permission denied EBUSY 10 Device busy ENODEV 11 No such device Cameron, Bates Expires: 20 Oct 93 [Page 9] Internet Draft CMP April 1993 ESECURITY 54 Security fault EMJOB 57 Job limit exceeded ESECURITYERR 59 Security server is unreachable Any other non-zero values may also be used to signify an error condition. 4. Multiplexed Messages A Multiplexed Message is the packet which is sent over the Multiplexed Connection. It is constructed from multiple data packets and their associated CMP headers. 4.1 Construction When an application to a subconnection sends a packet, the CMP prepends that packet with a header to create a CMP message, then appends the message to the Multiplexed Message under construction. When the first message to be transmitted is placed into the Multiplexed Packet under construction, a timer is started. When the timer expires, all outstanding message are placed into the Multiplexed Message and it is transmitted. This ensures that all messages constructed before the timer expires are sent in a single Multiplexed Message. If during construction of the Multiplexed Message the buffer holding the packet fills, the Multiplexed Message is transmitted immediately. The delay time should be user configurable; a reasonable time is 20 to 30 milliseconds. Additionally, configuration options may limit the number of included data packets or the maximum size of the Multiplexed Message before it is transmitted. If urgent data arrives for a subconnection, this is added to the Multiplexed Message, which is transmitted immediately (see section 3.5). 4.2 Disassembly When a Multiplexed Message is received, the CMP immediately accepts it from TCP. It is important that the TCP connection be kept drained so that the window remains open. Each message in the Multiplexed Message (i.e. data message or control message) is processed in turn. The data contained in DATA and URG_DATA messages is sent to the applications as though they were directly interfaced to TCP. All other message types are dealt with by the CMP interface layer. Cameron, Bates Expires: 20 Oct 93 [Page 10] Internet Draft CMP April 1993 5. Security Considerations If a site's security is instituted on an host-to-host basis, the CMP does not introduce a security problem. If security exists on a per connection basis, the CMP would need to provide a mechanism for allowing or disallowing certain users access to a multiplexed connection. Such a mechanism could be added, but is beyond the scope of this document. 6. Authors' Addresses Peter Cameron and Julian Bates Xylogics International Ltd. Featherstone Road Wolverton Mill Milton Keynes MK12 5RD UK Phone: +44 908 222112 Fax: +44 908 222115 Email: cmp-id@xylint.co.uk Cameron, Bates Expires: 20 Oct 93 [Page 11]